The invention relates to a method for congestion management in a frame relay network, wherein a virtual channel associated with a frame to be transferred is determined. The invention further relates to a node in a frame relay network, comprising at least one resource liable to congestion, such as a buffer.
Congestion means a situation in which the number of transmission requests exceeds the transmission capacity at a certain network point (called a bottle-neck resource) at a specific time. Congestion usually results in overload conditions, as a result of which the buffers overflow, for instance, and so packets will be retransmitted either by the network or the subscriber. The function of congestion management (CM) is to maintain a balance between the transmission requests and the transmission capacity so that the bottle-neck resources operate on an optimal level, and the subscribers are offered service in a way that assures fairness.
Congestion management can be divided into congestion avoidance (CA) and congestion recovery (CR). Congestion avoidance methods aim at preventing the occurrence of congestion in the network by dynamically adjusting the bandwidth of the subscribers in accordance with network congestion conditions and/or by altering the network routing so that part of the traffic load of the bottle-neck resources is shifted to idle resources. The purpose of recovery methods, in turn, is to restore the operation of the bottle-neck resources to an optimal level if the avoidance methods have failed to prevent the occurrence of congestion.
The frame relay (FR) technique is a packet-switched network technique used for the transmission of frames of varying length in place of the packet-switched network connections presently in use. The protocol (X.25) applied generally in the present packet-switched networks requires plenty of processing and the transmission equipment is expensive, as a result of which the speeds also remain low. These matters are due to the fact that the X.25 standard was developed when the used transmission connections were still rather prone to transmission errors. The starting point of the frame relay technique was a considerably lower transmission line error probability. It has therefore been possible to discard a number of unnecessary functions in the frame relay technique, thus making the delivery of frames rapid and efficient. The Frame Mode Bearer Service is described generally in the CCITT specification I.233 (Reference 1) and the associated protocol in the specification Q.922 (Reference 2). Congestion in an FR network and congestion management mechanisms are described in the CCITT specification I.370 (Reference 3). For a more detailed description of the FR technique, An Overview of Frame Relay Technology, Datapro Management of Data Communications, McGraw-Hill Incorporated, April 1991, (Reference 4) as well as the above-mentioned specifications are referred to.
The recommendations defined in the CCITT specifications offer a few mechanisms for congestion notification. For instance, the recommendation I.370 shares the network congestion management between the nodes and the subscribers of the network. According to it, the subscriber should adjust the amount of traffic on the basis of congestion notifications received from the network, and the network, in turn, should do the same on the basis of congestion notifications received from the subscriber. In other words, if the network notifies the subscriber of congestion, the subscriber should reduce its traffic to the network, and vice versa. This co-operation would thus make the network a kind of closed system as far as the congestion management is concerned. However, this kind of congestion management is not operative in practice, mainly for two reasons:
--notification mechanisms offered by the specification are too slow to respond to momentary congestion situations; and
--one cannot rely on the subscribers voluntarily reducing traffic even if they receive congestion notifications from the network. In such a case the congestion management system is not, in fact, closed, and congestion will not be relieved.
Another drawback of known methods is that all subscribers are treated equally under congestion conditions, and so it is not possible to give priority to the messages of subscribers wanting better service (i.e. applications requiring better service) with respect to the throughput probability.